Subject: LF bits propagation

From: [email-masked]
Date: Fri, 15 Jul 94 18:06:30 EDT

Connect RIGlet,

Here aresome more commentsmy to the LF proposal. I am only
including segments from previous comments to keep the append short.
My comments are marked with a >>>.

>Cache and XID3s
>===============
>
>If the Origin DLSw is aware that it is dealing with an SNA station that uses
>XID3s (which will be the case if it is issuing the CUR_cs as a result of
>receiving an XID3), it could avoid the failure of the circuit setup attempt by
>modifying the XID3 max BTU size field.  However this requires that the Target
>does not fail the circuit setup attempt if the LF bits don't match.
>
>For this to be possible, let's use one of the reserved bits in Wayne's LF Size
>field to mean "don't care if you return a smaller size".  If this bit, say the
>top bit, is set, it instructs the Target DLSw to use the LF size specified
>in the CUR_cs when issuing the TEST frame, but to return the ICR_cs with
>whatever value is obtained for LF size even if it is smaller.  The Origin DLSw
>is then responsible for deciding whether to drop the circuit by issuing
>a HALT_DL_NOACK or to continue and issue the REACH_ACK.
>
>This bit may also prove useful in the future for other DLC types where the
>Origin DLSw can guarantee that the Origin end station will act on any LF size
>returned on the ICR_cs.
>
>Note that the Origin DLSw is not required to support this use of XID3s (or
>other mechanisms for LF size propagation), but the Target DLSw is required
>to implement the 2 lines of code needed to support this bit flag (in addition
>to the LF Size field support).

>>> I think 2 FSM changes are required to support the latest LF proposal for
>>> handling the 2 cases when there is a problem with the LF size.
>>> (1) Changes similiar to the following would be required to support the decision not
>>>     to send the ICANREACH_cs back to the origin DLSw if the LF size of the route
>>>     obtained on the target DLSw is smaller than the origin DLSw LF size.
>>>
>>> RESOLVE_PENDING
>>>
>>> Event                           Action                             Next State
>>>
>>> DLC_DL_STARTED        if (LF from DLC_DL_STARTED >=       if (LF from DLC_DL_STARTED >=
>>>                           LF from DLC_START_DL) ||            LF from DLC_START_DL )&&
>>>                           don't care flag is set:             don't care flag is set:
>>>                               send ICANREACH_cs                   CIRCUIT_PENDING
>>>                       else:                               else:
>>>                               DLC_HALT_DL                          HALT_PENDING_NOACK
>>>
>>> (2) Changes similar to the following would be required to support the "don't care"
>>>     feature when the origin DLSw decides to drop the circuit by issuing a HALT_DL_NOACK
>>>     instead of continuing with the circuit bringup by issuing a REACH_ACK.
>>>
>>> CIRCUIT_START
>>>
>>>
>>> Event                          Action                             Next State
>>>
>>> Receive ICANREACH_cs     if decision is drop circuit:        if decision is drop circuit:
>>>                                send HALT_DL_NOACK                DISCONNECTED
>>>                          else:                               else:
>>>                                send REACH_ACK                    if Connected:
>>>                                if Connected:                          CONNECT_PENDING
>>>                                   send CONTACT                   else:
>>>                                else:                                  CIRCUIT_ESTABLISHED
>>>                                   no action taken
>>>

>
>Minor Issues and comments
>=========================
>
>1)      We should probably specify which SSP frames are required to carry this
>        information.  This informations seems to make sense on CUR, ICR, NNQ,
>        NNR, XIDFRAME, DATAFRAME and DGRMFRAME messages only.
>

>>> I propose we propagate LF bits on the CUR_*, ICR_*, NNQ_*, NNR_*, XIDFRAME,
>>> CONTACT, CONTACTED, DATAFRAME, and DGRMFRAME SSP frames.
>>>

>>>  Comments ????
>>>  Wayne T.